Method and system for providing alert messages related to suspicious transactions

ABSTRACT

Systems and methods are provided for providing alerts to a user. The systems and methods may include a financial service provider including a memory device storing instructions, The financial service provider may also include at least one processor configured to execute the instructions to receive data relating to a transaction made by the user, compare the received data to a set of data associated with the user, determine whether the data relating to the transaction deviates from a set of data associated with the user by more than a threshold value, and send an alert message to a user device associated with the user when the processor determines that the data relating to the transaction deviates from the set of data associated with the user by more than the threshold value.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/933,942, filed Jul. 20, 2020, which is a continuation of U.S. patentapplication Ser. No. 14/592,760, filed Jan. 8, 2015, which claims thebenefit of priority under 35 U.S.C. § 119 to U.S. provisional patentapplication Nos. 61/925,458, filed Jan. 9, 2014, and 62/032,838 filedAug. 4, 2014, both entitled “Method and System for Providing AlertMessages Related to Suspicious Transactions.” The aforementionedapplications are incorporated herein by reference in their entirety.

TECHNICAL FIELD

The present disclosure generally relates to systems and methods forproviding alert messages to users, and more particularly, to systems andmethods for providing alert messages related to suspicious transactionsto users of financial service products and services.

BACKGROUND INFORMATION

Fraudulent transactions and transaction disputes continue to increase inthe financial sector, raising ever-growing concerns for financialservice providers, consumers, and merchants. In particular, with thewide spread of e-commerce, user identities and financial information arebecoming more and more vulnerable to theft, bad faith merchantpractices, or other unauthorized use. When a user of a bank card oraccount notices an unauthorized transaction, or when the user otherwisedisputes a transaction made using the bank card or account, the user mayreport it to the financial institution, which may investigate thetransaction and attempt to resolve the dispute between the merchant andthe user, Monitoring every transaction, however, can impose a seriousburden on the user, particularly when the user has multiple bank cardsor accounts. In addition, users that observe a suspicious transactionassociated with a product or service purchased from a merchant may nothave the time and energy to dispute the transaction, which may not onlycause monetary loss to the users, but also encourage continued abusivepractices.

Financial institutions that issue or manage bank cards or accounts oftenhave anti-fraud systems for monitoring fraudulent transactions. When afraudulent transaction is detected, the anti-fraud systems may notifythe user. Such anti-fraud systems, however, lack the capability toprovide precautionary notifications to users about suspicioustransactions that may not be fraudulent but have an increased likelihoodof being subject to future disputes. In addition, existing anti-fraudsystems typically rely primarily on crowd-sourced feedback, which maynot provide an accurate detection of suspicious transactions.Accordingly, there is a need for methods and systems for assisting usersin identifying suspicious transactions.

SUMMARY

Disclosed examples provide methods and systems for providing alerts to auser, particularly alert messages related to suspicious transactionsassociated with financial service products and services. Aspects of thedisclosed methods and systems may reduce burdens on the individualassociated with monitoring such transactions, and may provide aconvenient, efficient, and easy-to-use solution for identifyingpotentially risky or suspicious transactions. For example, the disclosedmethods and systems may notify a user that a merchant may have a lowrating or poor review before the user completes a transaction with themerchant. The disclosed methods and systems may also notify a user thata transaction is inconsistent with a pattern associated with the user.This may assist the user in making an informed decision about whetherthe transaction should be cancelled to avoid potential trouble andfuture disputes. This may also assist the user to watch for suspiciousactivities associated with the user's financial accounts (e.g., bankcards, credit cards).

Consistent with one example, a system for providing alerts to a user isprovided. The system may include a memory device storing instructions.The system may also include at least one processor configured to executethe instructions to receive data relating to a transaction made by theuser, compare the received data to a set of data associated with theuser, determine whether the received data relating to the transactiondeviates from the set of data associated with the user by more than athreshold value, and send an alert message to a user device associatedwith the user when the processor determines that the data relating tothe transaction deviates from the set of data associated with the userby more than the threshold value.

Consistent with another example, a computer-implemented method forproviding alerts to a user is provided, the method may include aplurality of operations performed by at least one processor. Theoperations may include receiving data relating to a transaction made bythe user and comparing the received data to a set of data associatedwith the user. The operations may also include determining whether thedata relating to the transaction deviates from the set of dataassociated with the user by more than a threshold value, The operationsmay further include sending an alert message to a user device associatedwith the user when the processor determines that the data relating tothe transaction deviates from the set of data associated with the userby more than the threshold value.

Consistent with other examples, tangible, non-transitorycomputer-readable storage media may store program instructions that areexecutable by one or more processors to implement any of the processesdisclosed herein, In one example, a non-transitory computer-readablemedium is provided. The non-transitory computer-readable medium may beencoded with instructions that, when executed by at least one processor,cause the at least one processor to perform a plurality of operations.The operations may include receiving data relating to a transaction madeby the user and comparing the received data to a set of data associatedwith the user. The operations may also include determining whether thedata relating to the transaction deviates from the set of dataassociated with the user by more than a threshold value. The operationsmay further include sending an alert message to a user device associatedwith the user when the processor determines that the data relating tothe transaction deviates from the set of data associated with the userby more than the threshold value.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory only,and are not restrictive of the disclosed examples.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate several embodiments and, togetherwith the description, serve to explain the disclosed principles. In thedrawings:

FIG. 1 is a diagram of an exemplary system that may be used to providealerts to users, consistent with the present disclosure.

FIG. 2 is a component diagram of an exemplary financial serviceprovider, consistent with the present disclosure.

FIG. 3 is a component diagram of an exemplary user device, consistentwith the present disclosure.

FIG. 4 is a flowchart of an exemplary method for providing alerts tousers, consistent with the present disclosure.

FIG. 5 is a flowchart of an exemplary method for providing pre-purchasealert messages to users, consistent with the present disclosure.

FIG. 6 is an exemplary pre-purchase alert message displayed on a userdevice of a user, consistent with the present disclosure.

FIG. 7 is an exemplary method for providing post-purchase alert messagesto users, consistent with the present disclosure.

FIG. 8 is an exemplary post-purchase alert message displayed on a userdevice of a user, consistent with the present disclosure.

FIG. 9 is another exemplary post-purchase alert message displayed on auser device of a user, consistent with the present disclosure.

FIGS. 10A and 10B show an exemplary user interface for providing ratingsand reviews of merchants to users, consistent with the presentdisclosure.

FIG. 11 is a flowchart of an exemplary method for providing adifferentiated dispute workflow, consistent with the present disclosure.

FIG. 12 is a flowchart of an exemplary method for providing an alertmessage to a user, consistent with the present disclosure.

DESCRIPTION OF THE EMBODIMENTS

Reference will now be made in detail to exemplary embodiments, examplesof which are illustrated in the accompanying drawings and disclosedherein. Wherever convenient, the same reference numbers will be usedthroughout the drawings to refer to the same or like parts.

The disclosed examples are directed to systems and methods for providingalerts to customers (or users) of financial service providers. Acomputer-executed software application (“app”), such as an FSP app, maybe provided by a financial service provider (“FSP”). The FSP app mayidentify that a user has made or will make a transaction at a merchant,and may provide an alert message to the user regarding the transactionand/or the merchant. The alert message may take any suitable form, suchas, for example, an electronic message, text message, multimediamessage, online post, in-app alert, etc. The FSP may be a bank, a creditcard company, an investment company, or other entity which handlesfinancial transactions for individuals and/or merchants. Financialtransactions may include, for example, payment of a user purchase ofproducts or services from a merchant using a credit card, debit card,bank account, loyalty card, etc. The FSP app may be a standalonesoftware application executed by FSP server processor(s). Additionallyor alternatively, the FSP app may be a standalone software applicationfor a personal computing device, such as personal computer software or amobile device app. The FSP app may be part of another softwareapplication provided by the FSP for managing finances related tobanking, credit accounts, debit accounts, etc.

The FSP may identify suspicious transactions. Suspicious transactionsmay include fraudulent transactions or transactions that are notnecessarily fraudulent but are likely to be subject to future disputes.The FSP may identify suspicious transactions before, during, or afterthe FSP customers conduct such transactions. For example, after the FSPidentifies a suspicious transaction, the FSP app may send an alertmessage to the user to caution the user that the transaction appears tobe out of a normal range of amounts or volumes, the transaction may befraudulent, or that the merchant has poor ratings or reviews, which maymean that the products and/or services purchased from the merchant mayhave a high likelihood of being subject to future disputes. Based on auser response received from the user, the FSP may provide, e.g., throughthe FSP app, further information to the user regarding the merchant,such as ratings and reviews of the merchant, to assist the user to makea decision as to whether the transaction should be avoided or canceledto avoid future trouble or disputes. Thus, disclosed methods and systemsmay ultimately reduce the likelihood of fraud, dispute, and abuse.

FIG. 1 shows a diagram of an exemplary system that may be configured toprovide alerts to users, consistent with disclosed examples. Thecomponents and arrangements shown in FIG. 1 are not intended to limitthe disclosed examples, as the components used to implement thedisclosed processes and features may vary.

In accordance with disclosed examples, an alert system 100 may includean FSP 110. FSP 110 may be a bank, a credit card company, a lender, orother type of financial service entity that generates, provides,manages, and/or maintains financial service accounts for one or moreusers, such as credit cards, debit cards, etc. FSP 110 may operate atleast one server 111. Server 111 may be a computer-based systemincluding computer system components, desktop computers, workstations,tablets, hand held computing devices, memory devices, and/or internalnetwork(s) connecting the components. Server 111 is discussed inadditional detail with respect to FIG. 2, below.

User 120 may operate a user device 120A, which may be a desktopcomputer, laptop, tablet, smartphone, multifunctional watch, pair ofmultifunctional glasses, tracking device, or any suitable device withcomputing capability, User device 120A may have the FSP app installedthereon, which may enable user device 120A to communicate with FSP 110,such as server 111, through a network 130. User device 120A is discussedin additional detail with respect to FIG. 3, below.

Network 130 may comprise any type of computer networking arrangementused to exchange data. For example, network 130 may be the Internet, aprivate data network, a virtual private network using a public network,a WiFi network, a LAN or WAN network, and/or other suitable connectionsthat may enable information exchange among various components of alertsystem 100. Network 130 may also include a public switched telephonenetwork (“PSTN”) and/or a wireless cellular network. Network 130 may bea secured network or unsecured network.

Merchant 140 may be a company that sells products and/or services, suchas a grocery store, an online retailer, or an auto repair shop, etc.Merchant 140 may include at least one server 141. Server 141 may be anysuitable server known in the art, which may include at least oneprocessor, a storage device, such as a hard drive or a memory, and aninput/output interface, such as a network communication interface, whichare not shown in FIG. 1. In some aspects, server 141 may include thesame or similar configuration and/or components of server 111. Server141 may include a computer-based system, which may include hardwareand/or software installed therein for performing methods and processesdisclosed herein. Server 141 may also enable merchant 140 to sellproducts and/or services through network 130 to user 120. For example,user 120 may use user device 120A to browse a webpage of merchant 140that runs on server 141, and may make a purchase of products or servicesoffered by merchant 140 through the webpage. Server 141 may communicatewith server 111 of FSP 110. For example, user 120 may use a bank cardmanaged by FSP 110 to purchase products or services from merchant 140,and merchant 140 may report such a transaction to server 111 in orderto, for example, verify authentication information about the bank cardused by user 120.

Alert system 100 may also include a third party server 150. Third partyserver 150 may communicate with at least one of FSP 110, merchant 140,and user device 120A via network 130. Third party server 150 may beassociated with a third party. The third party may be, for example, abank other than FSP 110, a credit reporting agency, a social networkcompany, a rating company, a survey company, or any other suitable datareporting source. Third party server 150 may provide information or datato at least one of FSP 110, merchant 140, or user device 120A, forexample, in some examples, third party server 150 may send ratings andreviews data about merchant 140 to FSP 110 and/or user device 120A. Insome examples, third party server 150 may send data relating to a creditrating of user 120 to FSP 110. In some examples, third party server 150may provide location information about user 120 to FSP 110.

Other components known to one of ordinary skill in the art may beincluded in alert system 100 to process, transmit, provide, and receiveinformation consistent with the disclosed examples. In addition,although not shown in FIG. 1, components of system 100 may communicatewith each other through direct communications, rather than throughnetwork 130. Direct communications may use any suitable technologies,including, for example, Bluetooth™, Bluetooth LE™, WiFi, near fieldcommunications (NFC), or other suitable communication methods thatprovide a medium for transmitting data between separate devices.

FIG. 2 shows a diagram of an exemplary financial service provider(“FSP”) 110, consistent with disclosed examples. As shown, FSP 110 mayinclude at least one server 111. Although discussed here in relation toFSP 110, it should be understood that variations of server 111 may beused by other components of alert system 100, including server 141 ofmerchant 140, user device 120A, and third party server 150. Server 111may be a single server or may be configured as a distributed computersystem including multiple servers or computers that interoperate toperform one or more of the processes and functionalities associated withthe disclosed examples.

Server 111 may include one or more processors 220, an input/output(“I/O”) device 230, and a memory 240. Processor 220 may be one or moreknown processing devices, such as a microprocessor from the Pentium™family manufactured by Intel™ or the Turion™ family manufactured byAMD™. Processor 220 may constitute a single core or multiple coreprocessor that executes parallel processes simultaneously. For example,processor 220 may be a single core processor configured with virtualprocessing technologies. In certain examples, processor 220 may uselogical processors to simultaneously execute and control multipleprocesses. Processor 220 may implement virtual machine technologies, orother known technologies to provide the ability to execute, control,run, manipulate, store, etc. multiple software processes, applications,programs, etc. In another example, processor 220 may include amultiple-core processor arrangement (e.g., dual. quad core, etc.)configured to provide parallel processing functionalities to allowserver 111 to execute multiple processes simultaneously. One of ordinaryskill in the art would understand that other types of processorarrangements could be implemented that provide for the capabilitiesdisclosed herein.

FSP 110 may include one or more storage units configured to storeinformation used by processor 220 (or other components) to performcertain functions related to the disclosed examples. In one example,server 111 may include memory 240. Memory 240 may store one or moreoperating systems that perform known operating system functions whenexecuted by processor 220. By way of example, the operating systems mayinclude Microsoft Windows™, Unix™, Linux™, Android™, Apple™ Computerstype operating systems, or other types of operating systems.Accordingly, examples of the disclosed invention may operate andfunction with computer systems running any type of operating system.Memory 240 may store instructions to enable processor 220 to execute oneor more applications, such as server applications, an alert application,network communication processes, and any other type of application orsoftware. Alternatively, the instructions, application programs, etc.,may be stored in an external storage (not shown) in communication withserver 111 via network 130 or any other suitable network. Memory 240 maybe a volatile or non-volatile, magnetic, semiconductor, tape, optical,removable, non-removable, or other type of storage device or tangible(i.e., non-transitory) computer-readable medium.

In one example, memory 240 may be encoded with one or more programs 250.Programs 250 stored in memory 240, and executed by processor 220, mayinclude an FSP app 252. FSP app 252 may cause processor 220 to executeone or more processes related to financial services provided tocustomers including, but not limited to, processing credit and debitcard transactions, checking transactions, fund deposits and withdrawals,transferring money between financial accounts, lending loans, processingpayments for credit card and loan accounts, identifying potentiallysuspicious transactions which may be fraudulent or likely to be subjectto disputes, sending alerts to user 120 regarding such transactions,providing ratings and reviews of merchants to user 120, and/orprocessing transaction disputes. In some examples, programs 250 may bestored in an external storage device, such as a cloud server locatedoutside of server 111, and processor 220 may execute programs 250remotely.

Server 111 may further include a storage device 260, which may be avolatile or non-volatile, magnetic, semiconductor tape, optical,removable, non-removable, or other type of storage device or tangible(i.e., non-transitory) computer-readable medium. For example, storagedevice 260 may include at least one of a hard drive, a flash drive, amemory, a Compact Disc (CD), a Digital Video Disc (DVD), or a Blu-ray™disc. Storage device 260 may store data that may be used by processor220 for performing various methods and processes disclosed herein. Datastored at storage device 260 may include historical fraud or disputesdata, transaction data, credit rating of user 120 and/or merchant 140,ratings and reviews of merchant 140. Historical fraud or disputes datamay include past fraud or disputes involving transactions related tomerchant 140 and/or user 120 resolutions of the fraud or disputes,patterns of fraud or disputes associated with merchant 140 and/or user120, correlations between merchant 140, types of products and/orservices, and user 120 involved in such fraud or disputes. Although notshown in FIG. 2, storage device 260 may store programs 250.

Server 111 may include at least one database 270. Database 270 may storedata that may be used by processor 220 for performing methods andprocesses associated with disclosed examples. Data stored in database270 may include any suitable data, such as information relating to user120 and/or merchant 140, information relating to transactions, andinformation relating to ratings and reviews of merchant 140. Database270 may store data that are similar to those stored in storage device260. Although shown as a separate unit in FIG. 2, it is understood thatdatabase 270 may be part of memory 240, storage device 260, or anexternal storage device located outside of server 111.

At least one of memory 240, storage device 260, and/or database 270 maystore data and instructions used to perform one or more features of thedisclosed examples. At least one of memory 240, storage device 260and/or database 270 may also include any combination of one or moredatabases controlled by memory controller devices (e.g., server(s),etc.) or software, such as document management systems, Microsoft SQLdatabases, SharePoint databases, Oracle™ databases, Sybase™ databases,or other relational databases. Server 111 may also be communicativelyconnected to one or more remote memory devices (e.g., databases (notshown)) through network 130 or a different network. The remote memorydevices may be configured to store information and may be accessedand/or managed by server 111. Systems and methods consistent withdisclosed examples, however, are not limited to separate databases oreven to the use of a database.

Server 111 may also include at least one I/O device 230 that maycomprise one or more interfaces for receiving signals or input fromdevices and providing signals or output to one or more devices thatallow data to be received and/or transmitted by server 111. For example,server 111 may include interface components, which may provideinterfaces to one or more input devices, such as one or more keyboards,mouse devices, and the like, which may enable server 111 to receiveinput from an operator of FSP 110 (not shown).

FIG. 3 shows an exemplary configuration of user device 120A, consistentwith disclosed examples. User device 120A may allow one or more FSP 110customers, such as user 120, to receive alerts regarding transactionsand/or merchant 140, User device 120A may be a personal computingdevice. For example, user device 120A may be a general purpose ornotebook computer, a mobile device with computing ability, a tablet, asmartphone, or any combination of these computers and/or affiliatedcomponents. In one example, user device 120A may be a computer system ormobile computer device that is operated by user 120 who is an FSP 110customer.

User device 120A may be configured with storage that stores one or moreoperating systems that perform known operating system functions whenexecuted by one or more processors. By way of example, the operatingsystems may include Microsoft Windows™, Unix™, Linux™, Android™, Apple™Computers type operating systems, or other types of operating systems.Accordingly, examples of the disclosed invention may operate andfunction with computer systems running any type of operating system.User device 120A may also include communication software that, whenexecuted by a processor, provides communications with network 130, suchas Web browser software, tablet or smart hand held device networkingsoftware, etc.

User device 120A may include a display 310 displaying information.Display 310 may include, for example, liquid crystal displays (LCD),light emitting diode screens (LED), organic light emitting diode screens(OLED), a touch screen, and other known display devices. Display 310 maydisplay various information to user 120. For example, display 310 maydisplay an alert message to user 120 about a transaction associated witha merchant. Display 310 may display touchable or selectable options foruser 120 to select, and may receive user selection of options through atouch screen or 110 devices 320.

I/O devices 320 may include one or more devices that allow user device120A to send and receive information from user 120 or another device.I/O devices 320 may include various input/output devices, such as akeyboard, a mouse-type device, a gesture sensor, an action sensor, aphysical button, a camera, oratory input, etc. I/O devices 320 may alsoinclude one or more communication modules (not shown) for sending andreceiving information from other components in alert system 100 by, forexample, establishing wired or wireless connectivity between user device120A and network 130, by establishing direct wired or wirelessconnections between user device 120A and server 111, or between userdevice 120A and merchant server 141. In some examples, user device 120Amay also include a Global Positioning System (GPS) unit 324. GPS 324 mayenable FSP 110 to receive location data of user device 120A fordetermining the location of user 120.

Other technologies may also be used for locating user 120, For example,user device 120A may use beacon technology. When user 120 walks into astore of merchant 140, user device 120A may communicate with a beacondevice provided at merchant 140. The beacon device may send informationreceived from user device 120A to server 111, thereby allowing server111 to determine that user 120 is located at merchant 140. For anotherexample, user device 120A may scan a bar code at merchant 140, and mayprovide the bar code information to server 111, Server 111 may determinethe location of merchant 140 based on the bar code information, therebydetermining the location of user device 120A, hence user 120, In someexamples, user device 120A (and/or another component of system 100) maydetermine user 120's location based on a user “checking in” via a socialnetworking site (i.e., Facebook™, Foursquare™, etc.).

User device 120A may include at least one processor 330, which may beone or more known computing processors, such as those described withrespect to processor 220 in FIG. 2. Processor 330 may execute variousinstructions stored in user device 120A to perform various functions,for example, processing an alert message received from server 111regarding a suspicious transaction and displaying the alert message ondisplay 310.

User device 120A may include a memory 340, which may be a volatile ornon-volatile, magnetic, semiconductor, tape, optical, removable,non-removable, or other type of storage device or tangible (i.e.,non-transitory) computer-readable medium. Memory 340 may store one ormore programs 350. Programs 350 may include operating systems (notshown) that perform known operating system functions when executed byone or more processors. Disclosed examples may operate and function withcomputer systems running any type of operating system. User device 120Amay be a device that executes mobile applications for performingoperations consistent with disclosed examples, such as a tablet ormobile device.

Programs 350 may also include an FSP app 352. Similar to FSP app 252executed by server 111 FSP app 352 may be executed by processor 330 toperform processes related to financial services including, but notlimited to, receiving data from server 111 regarding suspicioustransactions, receiving data from server 111 regarding ratings andreviews of merchant 140, receiving alert messages from server 111 anddisplaying the alert messages on display 310, providing location data toserver 111, receiving input from user 120 in response to the alertmessages, and sending user input data to server 111.

FIG. 4 shows a flowchart of an exemplary method 400 for providing alertsto user 120. For discussion purposes, the exemplary methods discussed inthis disclosure (including the method 400) are described as performed byserver 111. In some examples, however, user device 120A and/or server141 of merchant 140 may perform one or more disclosed method steps. Insome examples, different components of alert system 100 (such as server111, server 141, and user device processor 330) may perform varioussteps of the methods in a distributed-computing configuration.

In step 410, server 111 may receive data relating to an activity of user120. The data relating to the activity of user 120 may include, forexample, GPS data received from GPS 324 indicating that user 120 is nearor at merchant 140, such as a grocery store, an auto repair shop, anelectronic devices retailer, etc. The data relating to the activity ofuser 120 may also include, for example, data indicating that user 120 isabout to make or has made a purchase of products and/or services atmerchant 140. In some aspects, data indicating that user 120 is about tomake or has made a purchase may include data indicating the user hasswiped a bank card on a point of sale terminal at merchant 140. The datarelating to the activity of user 120 may further include, for example,location data received from a third party indicating that user 120 haslogged into a third party application or has “checked in” using thethird party application while user 120 is at or near merchant 140. Insome examples, when user 120 logs into the third party application orremains logged in, the third party application may obtain locationinformation about user 120 and send location information to user device120A and/or server 111. The third party application may include, forexample, an online chat application, a social network application, atracking application, etc.

The data relating to an activity of user 120 may also include dataindicating suspicious transactions. The data relating to the activity ofuser 120 may include, for example, the type of transaction. For example,server 111 may detect that a purchase for gasoline (type of transaction)was made with a credit card belonging to a user who is known not to owna vehicle, and/or did not recently rent a vehicle. Server 111 maydetermine that this type of transaction is out of the scope of theuser's normal purchases. Based on the determination, server 111 may sendan alert to user 120.

The data relating to the activity of user 120 may also include thefrequency (repetition) of the transaction. For example, server 111 maydetect that three transactions for TVs were made within one weekinvolving different merchants, or on the same day with the same merchant(e.g., repeated transactions). Server 111 may determine that thisfrequency (e.g. repeated transactions) indicates that the transactionsare suspicious. Based on the determination, server 111 may send an alertto user 120.

The data relating to the activity of user 120 may also include dataindicating a transaction amount or volume. Server 111 may analyze thetransaction amount or volume to determine a deviation (or variance) ofthe transaction amount or volume from a normal, average, or otherwiseallowable transaction amount or volume associated with the merchant. Forexample, server 111 may detect that a payment of $100 is made to autility company using a credit card or a checking account of user 120.Server 111 may analyze historical payments made to the utility companyby the user, and may determine that the $100 payment is $50 more than anormal, average, or allowable payment amount. Server 111 may determinethat this deviation is more than a threshold value (e.g., the thresholdvalue may be $30 for this utility company), and may send an alertmessage to user 120 asking user 120 to check the bill, for example.

The data relating to the activity of user 120 may also includegeographical information (e.g., the location) about the transaction. Forexample, server 111 may detect that a purchase was made at a merchantlocated over 250 miles from where user 120 typically makes purchases,and may determine that this purchase should trigger an alert to ask user120 to confirm whether this purchase is legitimate or ask user 120 tocall the financial institute if something is suspicious, for example.

Server 111 may assign a transactional score to each transaction. Thetransactional score may be based on any one or a combination of thefactors discussed above, e.g., type of transaction, frequency oftransaction, deviation of transaction amount or volume, and geographicalinformation about the transaction. If the transactional score is higherthan a predetermined threshold, for example, the transaction may belegitimate, and an alert may not be triggered. And if the transactionalscore is lower than the predetermined threshold, the transaction may beinvalid, and an alert may be triggered.

The data relating to an activity of user 120 may also include other dataindicating, for example, large bill variance (e.g., variance of billpayment larger than a predetermined threshold), and small bill variance(e.g., variance of bill payment smaller than a predetermined threshold).The data may also include data indicating performance related to abudget for a certain category. For example, user 120 may have allocateda certain budget for particular spending categories, and the data mayinclude information indicating that spending has or has not, or may soonexceed the budget for certain categories, the amount of excessivespending, etc.

In step 420, server 111 may determine whether the received data relatingto an activity of user 120 triggers an alert. If the received data doesnot trigger an alert (No, step 420), server 111 may continue to receivedata relating to activity of user 120. If the received data triggers analert (Yes, step 420), server 111 may continue to execute step 430.Server 111 may perform various processes to determine whether thereceived data relating to user activity triggers an alert. For example,server 111 may identify a merchant based at least on the received data.Server 111 may access and analyze historical fraud or disputes data,crowd-sourced feedback, etc., which may be associated with at least oneof the user and the merchant. Server 111 may determine whether theactivity involves or will likely involve a suspicious transaction thatmay be fraudulent, likely fraudulent, or likely to be subject todisputes, thereby determining whether the received data triggers analert. According to some examples, the historical fraud or disputes datamay comprise proprietary data collected by FSP 110 associated with FSP110 customer purchase transactions, identified or suspected fraud(perpetrated by unauthorized users of the financial product or service,customers of FSP 110, merchant(s) 140, etc.), disputed transactions (forexample, indicating the number and nature of disputed transactionsassociated with user 120 and/or merchant(s) 140), etc.

When server 111 determines that the received data relating to theactivity of user 120 indicates a suspicious transaction, server 111 maydetermine that an alert should be triggered. In step 430, server 111 maysend an alert message to user 120, e.g., to user device 120A of user120. The alert message may be displayed on display 310 of user device120A. The alert message may include options that may be selected by user120 to indicate whether user 120 desires to receive additionalinformation regarding the transaction and/or merchant. The additionalinformation may include, for example, ratings and reviews of merchant140. Additional example of alert messages will be described below withrespect to FIGS. 8-10B, in step 440, server 111 may receive a userresponse to the alert message, including a user selection of any optionspresented in the alert message. In step 450, server 111 may determine,based on the received user response, whether user 120 desires to receiveadditional information. If server 111 determines that user 120 does notwish to receive additional information (No, step 450), server 111 mayend method 400. If server 111 determines that user 120 wishes to receiveadditional information (Yes, step 450), server 111 may provide user 120with additional information in step 460.

FIG. 5 shows a flowchart of an exemplary method 500 for providing alertsto user 120. Method 500 may be executed by, for example, server 111 toprovide a pre-purchase alert to user 120. In step 510, server 111 mayreceive data relating to a pre-purchase activity of user 120. Forexample, server 111 may receive positioning data from GPS 324, via userdevice 120A, indicating the location of user 120. In another example,server 111 may receive positioning data from third party server 150 anddetermine the location of user 120. For example, third party server 150may receive user log in or check in information from user device 120Athrough a third party app installed on user device 120A, through awebsite visited by user 120 from user device 120A, etc. The third partyapp may include a function of acquiring user location through, forexample, GPS 324, the user inputting a geographic location, etc,Examples of such third party app include a chat app, tracking app,search engine app, social network app, such as FourSquare™.

The pre-purchase activity may also include user 120 swiping a bank cardto initiate a purchase, adding items to a virtual shopping cart of anonline merchant, etc. In some examples, server 111 may receive, frommerchant 140, data relating to the swipe of the bank card at a point ofsale terminal. For example, merchant 140 may request authorization tocomplete a purchase transaction using an account of user 120 held by FSP110. Server 111 may determine that user 120 is located at merchant 140and is about to make a purchase there.

In step 520, server 111 may determine whether the pre-purchase activitytriggers an alert. Continuing the above example, after determining thelocation of user 120, server 111 may analyze data relating to merchant140. It is to be understood, however, that server 111 need notnecessarily determine the location of user 120 to analyze data relatingto merchant 140 or to send pre-purchase alerts. In some examples, forexample, server 111 may receive a request from merchant 140 to authorizea purchase transaction but not know the location of merchant 140 or user120.

In some examples, server 111 may analyze historical fraud or disputesdata related to merchant 140. The historical fraud or disputes datarelated to merchant 140 may include, for example, how many fraudulenttransactions or disputes have involved merchant 140 in a pastpredetermined period of time (e.g., years, months, or days). Server 111may also analyze crowd-sourced feedback. Crowd-sourced feedback mayinclude ratings and reviews regarding merchant 140 collected from thegeneral public, rather than only from users of FSP 110. In one example,server 111 may primarily rely on historical fraud or dispute data,rather than crowd-sourced feedback, because historical fraud or disputedata from FSP 110 may provide a more accurate analysis result.

In addition, server 111 may determine which products sold by merchant140 are more likely to be subject to disputes. Server 111 may determinea pattern of disputes associated with merchant 140 based on, forexample, the historical fraud or dispute data of FSP 110. Server 111 mayalso analyze ratings and reviews of merchant 140 based on, for example,crowd-sourced feedback. Server 111 may assign a reputation score tomerchant 140 based on a result of at least one of the above analyses.Server 111 may compare the reputation score of merchant 140 to apredetermined threshold score and determine whether merchant 140 has ahigh reputation score or a low reputation score, as compared to thepredetermined threshold, for example. According to some examples, thethreshold score may be set or based on information provided by FSP 110,user 120, and/or a third party. Server 111 may determine that an alertshould be triggered, for example, when the comparison indicates thatmerchant 140 has a low reputation score.

When server 111 determines that the pre-purchase activity does nottrigger an alert (No, step 520), method 500 repeats step 510. Whenserver 111 determines that the pre-purchase activity triggers an alert(Yes, step 520), server 111 may send, in step 530, a pre-purchase alertmessage to user 120 (via, e.g., user device 120A). The pre-purchasealert message may be displayed on display 310 of user device 120A.

FIG. 6 shows an exemplary pre-purchase alert message 610 that may bedisplayed on display 310, as part of step 530. The pre-purchase alertmessage 610 may notify user 120 that user 120 appears to be located at(and/or initiating a purchase at) the merchant, e.g., Pete's Auto Shop,which has an elevated number of disputes. The pre-purchase alert message610 may ask user 120 whether user 120 would like to receive additionalinformation, such as ratings and reviews, about this merchant. Thepre-purchase alert message 610 may provide options, e.g., a Yes button620 and a No button 630, for user 120 to select to indicate whether user120 wishes to receive additional information about this merchant. User120 may select the Yes button 620 to indicate user's desire to receiveadditional information, or the No button 630 to indicate user's desirenot to receive additional information.

Referring back to FIG. 5, in step 540, server 111 may receive a userresponse to the pre-purchase alert message, which may include a userselection of the Yes button 620 or the No button 630. In step 550,server 111 may determine whether user 120 would like to receiveadditional information, such as the ratings and reviews of merchant 140,based on the user response received from user 120. If server 111determines that user 120 does not wish to receive additional information(No, step 550), server 111 may end method 500. If server 111 determinesthat user 120 wishes to receive additional information (Yes, step 550),server 111 may provide user 120 with additional information in step 560.For example, server 111 may send ratings and/or reviews informationabout merchant 140 to user device 120A, which may be displayed ondisplay 310. An example of providing ratings and/or reviews informationis discussed below in connection with FIG. 10. After reviewing theratings and/or reviews about merchant 140, user 120 may determinewhether or not to make or cancel the transaction.

FIG. 7 is a flowchart of an exemplary method 700 for providing alerts touser 120. Method 700 may be executed by, for example, server 111 toprovide a post-purchase alert to user 120. In step 710, server 111 mayreceive data relating to a purchase made by user 120. For example,server 111 may receive an electronic signature of user 120 or otherindication that a transaction has been finalized and approved by user120 at merchant 140 for products or services. In step 720, server 111may determine whether the data relating to the purchase should triggeran alert. Similar to the above discussion hi connection with step 520 inFIG. 5, server 111 may analyze historical fraud or disputes data relatedto merchant 140, the crowd-sourced feedback, the ratings and/or reviewsof merchant 140, the pattern of disputes, and/or the type of productsand/or services to determine whether the transaction may be a suspicioustransaction. For example, if merchant 140 has an elevated number ofdisputes in the past three months involving the same or similar type ofproducts or services, server 111 may determine that the transaction user120 has made could be a suspicious transaction that may either befraudulent or more likely to be subject to a dispute. Similar to theabove discussion with respect to a pre-purchase alert, server 111 mayassign a reputation score to merchant 140 based on at least one of theabove analyses, and may compare the reputation score to a predeterminedthreshold score to determine whether merchant 140 has a high or lowreputation score, as compared to the predetermined threshold, forexample. If server 111 determines that merchant 140 has a highreputation score, an alert may not be triggered. If server 111determines that merchant 140 has a low reputation score, an alert may betriggered.

If server 111 determines that an alert should not be triggered (No, step720), server 111 may repeat step 710. If server 111 determines that analert should be triggered (Yes, step 720), server 111 may send apost-purchase alert message to user 120, for example, through userdevice 120A. The post-purchase alert message may be displayed on display310.

An exemplary post-purchase alert message 810 is shown in FIG. 8.Post-purchase alert message 810 may identify the transaction that user120 has made at Pete's Auto Shop for $103.17, for example, and thatPete's Auto Shop is associated with an elevated number of disputes.Post-purchase alert message 810 may ask user 120 whether user 120 wouldlike to receive additional information, such as ratings and reviews,about this merchant. Post-purchase alert message 810 may provideoptions, e.g., a Yes button 820 and a No button 830, for user 120 toselect to indicate whether user 120 wishes to receive additionalinformation about this merchant. User 120 may select the Yes button 820to indicate user's desire to receive additional information, or mayselect the No button 830 to indicate user's desire not to receiveadditional information. If user 120 takes no action (i.e., does notselect the Yes button 820 or the No button 830) within a predeterminedperiod of time (e.g., one hour, one day, etc.) server 111 may send areminder message to user device 120A for user 120 to check on thetransaction. The reminder message may be similar to post-purchase alertmessage 810.

Referring back to FIG. 7, in step 740, server 111 may receive a userresponse to the post-purchase alert message, which may include userselection of the Yes button 820 or the No button 830. In step 750,server 111 may determine whether user 120 wishes to receive additionalinformation about merchant 140 based on the user response. For example,if user 120 has selected the No button 830, server 111 may determinethat user 120 does not wish to receive additional information aboutmerchant 140 (No, step 750), and server 111 may end method 700. If userhas selected the Yes button 820, server 111 may determine that user 120wishes to receive additional information about merchant 140 (Yes, step750), and server 111 may continue to execute step 760 to provide theadditional information to user 120. For example, server 111 may sendratings and/or reviews information about merchant 140 to user device120A, which may be displayed on display 310 to user 120. User 120 mayreview the ratings and/or reviews information about this merchant, andmay determine whether the transaction should be cancelled to avoid apotential dispute with merchant 140 in the future. For example, ifmerchant 140 has a low rating or poor review, as compared to othermerchants, for example, user 120 may determine that he/she should returnor cancel the purchase to avoid any future dispute. According to someexamples, server 111 may receive an indication from user 120 (via, e.g.,user device 120A) that the transaction should be cancelled, and server111 may initiate cancellation of the transaction based on the receivedindication.

FIG. 9 shows another exemplary post-purchase alert message 910 displayedon display 310 of user device 120A. In this example, the post-purchasealert message 910 may notify user 120 that the transaction may be tiedto a subscription. In some examples, server 111 may analyze the type oftransaction to determine whether the transaction is associated with asubscription or a recurring fee (weekly, monthly, annually, etc.). Forexample, if user 120 has made a purchase of a monthly magazine or ajournal, or paid an annual membership fee for a club, server 111 maydetermine that an annual subscription fee or membership fee is likelydue in the next twelve months. The post-purchase alert message 910 mayask user 120 whether user 120 would like to be reminded of thesubscription or annual fee due before the next recurring fee isexpected. Although twelve months is used as an example, other periods,such as three months or six months, may be determined by server 111 as asuitable period for reminding user 120, based on, for example,historical purchase data associated with user 120. The post-purchasealert message 910 may provide options, e.g., a Yes button 920 and a Nobutton 930. for user 120 to select to indicate whether user 120 wouldlike to receive a reminder. If user 120 selects the Yes button 920,server 111 may set up a reminder that will be sent to user device 120Ain 12 months about the subscription fee due or the annual fee due. Ifuser 120 selects the No button 930, server 111 may not set up areminder.

The pre-purchase alert message 610 and the post-purchase alert messages810 and 910 are for illustrative purpose only. Many other alert messagesmay be used in alert system 100. For example, pre-purchase alertmessages may include information that notifies user 120 of offers,promotions, benefits, or discounts provided by various bank cards. User120 may review the offers, promotions, benefits, or discounts associatedwith the bank cards on display 310, and may determine which bank cardshould be used for payment of the transaction. For example, in someexamples, pre-purchase alert messages may notify user 20 that a Bank Acredit card offers $10 off $50 at merchant 140. User 120 may determineto use Bank A credit card to take advantage of this offer. For anotherexample, pre-purchase alert messages may notify user 120 that Bank Bcredit card provides an extended warranty on the type of product user120 is about to purchase, if user 120 uses Bank B credit card to makethe purchase. User 120 may wish to take advantage of the extendedwarranty by using the Bank B credit card to pay the transaction.

In some examples, pre-purchase alert messages may also provideinformation to user 120 about offers, promotions, or discounts providedby merchant 140, such that user 120 may take advantage of the offers,promotions, or discounts by meeting certain requirements. For example,when server 111 determines that user 120 has swiped a credit card topurchase a TV, server 111 may retrieve information about offers,promotions, or discounts currently provided by merchant 140 from server141, analyze such information, and determine that merchant 140 currentlyoffers a 10% discount for a bundle purchase of a TV and a DVD player.Server 111 may provide a pre-purchase alert message to user 120 tonotify user 120 that if user 120 also purchases a DVD player, user 120may receive a 10% discount on the total purchase of a TV and a DVDplayer. User 120 may determine to take advantage of this discount bymaking an additional purchase of a DVD player from merchant 140. Inanother example, server 111 may collect offers, promotions, or discountsfrom various merchants, and may provide a comparison of prices, offers,promotions, or discounts offered by various merchants in favor of thisparticular merchant 140 to promote sales. Financial service provider 110may receive some financial incentive (e.g., 1% of the promoted salescompleted, regular payment, etc.) from merchant 140 for such services.

In some examples, post-purchase alert messages may similarly provideinformation regarding offers, promotions, benefits, or discountsprovided by a bank card or a merchant, as discussed above in connectionwith the exemplary pre-purchase alert messages. User 120 may determinewhether to make an additional purchase or to cancel or return a purchasebased on the offers, promotions, benefits, or discounts informationincluded in the post-purchase alert messages.

In some examples, post-purchase alert messages may be used for remindinguser 120 of recurring dues of credit card bills, utility bills,mortgage, loans, or tuitions. For example, user 120 may have used achecking account or a debit card to pay the credit card bills, utilitybills, mortgage, loans, or tuitions. Server 111 may determine the nextdue dates of various credit cards, utilities, mortgage, loans, ortuitions based on the past due dates, and may provide user 120 an optionto receive reminders for upcoming due dates. This may help user 120avoid any late payments.

FIGS. 10A and 10B show an exemplary user interface for providing ratingsand reviews of merchants to user 120. In the example shown in FIGS. 10Aand 10B, the user interface may take the form of a web page 1010 and aweb page 1060. Other forms of user interface, such as text-based tables,may also be used for providing ratings and reviews of merchants to user120. The user interface may be displayed on display 310, for example,after user 120 selects the Yes button 620, 820, or 920, consistent withthe above described examples. Web page 1010 may be related to afinancial institution, e.g., Bank A, which offers credit card A. Webpage 1010 may show details about user's account with Bank A. Forexample, web page 1010 may show transactions and details related tocredit card A. A first section 1030 of web page 1010 may show thecurrent balance and the amount due of credit card A. A second section1040 of web page 1010 may show a list of transactions made at differentmerchants A, B, C, D, E, F, and G. User 120 may click on one of themerchants to open up another web page 1060, for example, to viewadditional information about the selected merchant. Alternatively oradditionally, second section 1040 may display an alert message 1050associated with a merchant, such as merchant B, to alert user 120 thatthis merchant has an elevated rate of disputes, and may provide ahyper-link, such as the one named “Click for details” shown in FIG. 10A.User 120 may click or select the hyper-link to open up web page 1060,for example, to view details about this merchant.

Web page 1060 may display additional information about a merchant,including, for example, the name and address 1070 of merchant B, amessage 1080 indicating that Bank A has flagged this merchant because ofelevated number of disputes. Web page 1060 may also display customerratings and reviews 1090. Customer ratings and reviews information maybe received by server 111 from users of FSP 110, for example, as part ofhistorical disputes data, Customer ratings and reviews information mayalso be collected or retrieved by server 111 from various other sources.For example, server 111 may collect or retrieve ratings and reviewsinformation from third party websites, such as, for example, onlinemerchants, social network websites, the Better Business Bureau or otherbusiness rating entity, and/or any other entity providing a forum forcustomers to share their ratings and reviews about merchants.

FIG. 11 is a flowchart of an example method 1100 for providing adifferentiated dispute workflow, Method 1100 may be executed by, forexample, server 111. Server 111 may handle a dispute brought by user 120in different processes, depending on, e.g., whether the merchant has alow reputation score or whether the user 120 has a history of disputingtransactions and whether those disputed transactions were ultimatelydetermined to be valid transactions. In step 1110, server 111 mayreceive communication from a user to dispute a transaction made withmerchant 140. For example, server 111 may receive an electronic messageor indication of a telephone call from user 120 who wishes to dispute atransaction made with merchant 140. User 120 may claim that thetransaction is unauthorized, fraudulent, or that merchant 140 abuseduser 120 by overcharging, sending user 120 a defective product, refusingto accept a return, etc. Server 111 may determine whether merchant 140has a low reputation score in step 1120. Server 111 may perform similaranalyses discussed above in connection with FIGS. 5 and 7, including,for example, analysis of the historical fraud or disputes dataassociated with merchant 140, analysis of the ratings and reviews ofmerchant 140, analysis of the type of products and/or services, analysisof the number of disputes in the past predetermined time period, andanalysis of the pattern of disputes. Similar to the above discussion inconnection with FIGS. 5 and 7, server 111 may assign a reputation scoreto merchant 140 based on at least one of the above analyses. Forexample, if merchant 140 has an elevated number of disputes in the pastthree months, merchant 140 may receive a low reputation score. Ifmerchant 140 has a relatively low number of disputes in the past threemonths, merchant 140 may receive a high reputation score. Server 111 maycompare the reputation score of merchant 140 with a predeterminedthreshold reputation score to determine whether the reputation score ofmerchant 140 is high or low.

If server 111 determines that merchant 140 has a low reputation score(Yes, step 1120), server 111 may initiate an expedited disputeresolution process 1130 to resolve the dispute. The expedited disputeresolution process 1130 may resolve the dispute in an expedited manner.For example, because merchant 140 has a low reputation score, server 111may determine that the dispute brought by user 120 is more likelylegitimate, and a favorable solution should be given to user 120.According to some examples, expedited dispute resolution process 1130may include removing the transaction from the customer's accountimmediately (before investigating the dispute), and FSP 110 may absorbthe risk/cost of the transaction if the disputed transaction isultimately resolved in merchant 140's favor. If server 111 determinesthat merchant 140 does not have a low reputation score (No, step 1120),server 111 may initiate a standard dispute resolution process 1130 toresolve the dispute. For example, because merchant 140 has a highreputation score, which may mean merchant 140 is not often involved indisputes, a standard dispute resolution process 1140 should be taken toresolve the dispute. The standard dispute resolution process 1140 mayperform a more thorough investigation about the transaction, themerchant, and the user to resolve the dispute. Thus, the standarddispute resolution process 1140 may take longer time to resolve thedispute than the expedited dispute resolution process 1130.

Although not shown in FIG. 11, it is understood that the differentiateddispute workflow may also be based on a reputation score of user 120 ora transactional score of the transaction, instead of a reputation scoreof merchant 140. Additionally, the differentiated dispute workflow maybe based on a combined score with at least one of the reputation scoreof user 120, the reputation score of merchant 140, and the transactionalscore. In other words, server 111 may decide whether the dispute shouldbe processed with the expedited dispute resolution process 1130 or thestandard dispute resolution process 1140 based on the reputation scoreof user 120, the reputation score of merchant 140, or the transactionalscore, or any combination of these scores. In some examples, a userreputation score may identify whether the user has a history ofdisputing transactions, whether those disputes were resolved in favor ofuser 120 or merchant 140, whether the user is considered by FSP 110 tobe in good standing, or whether the user is a participant in program(s)that include expedited dispute resolution as a benefit, etc. Forexample, in one example, server 111 may process the dispute with theexpedited dispute resolution process 1130 when it determines that user120 has a high reputation score, as compared to the predeterminedthreshold, for example, or when it determines that the combinedreputation score is low (indicating, for example, user 120 has a highreputation score and merchant 140 has a low merchant score). Server 111may process the dispute with the standard dispute resolution process1140 when it determines that user 120 has a low reputation score, orwhen it determines that the combined reputation score of user 120 andmerchant 140 is high (indicating, for example, user 120 has a lowreputation score and merchant 140 has a high merchant score).

In some examples, server 111 may determine whether the transactionalscore is higher than a predetermined threshold score. If thetransactional score is higher than the predetermined threshold score,which may indicate that the transaction is more likely valid, server 111may process the dispute with the standard dispute resolution process1140. If the transactional score is lower than the predeterminedthreshold score, which may indicate that the transaction is more likelyinvalid, server 111 may process the dispute with the expedited disputeresolution process 1130.

In some examples, server 111 may determine whether a combined score,which may combine at least one of the reputation score of user 120, thereputation score of merchant 140, or the transactional score, is higheror lower than a predetermined threshold score. The combination mayassign different weights (e.g., 20%, 50%, 30%) to the reputation scoreof user 120, the reputation score of merchant 140, and/or thetransactional score. If the combined score is higher than thepredetermined threshold score, which may indicate that the transactionis more likely valid, server 111 may process the dispute with thestandard dispute resolution process 1140. If the combined score is lowerthan the predetermined threshold score, which may indicate that thetransaction is more likely invalid, server 111 may process the disputewith the expedited dispute resolution process 1130.

The foregoing description has been presented for purposes ofillustration. It is not exhaustive and is not limited to the preciseforms or examples disclosed. Modifications and adaptations of theexamples will be apparent from consideration of the specification andpractice of the disclosed examples. For example, the describedimplementations include hardware and software, but systems and methodsconsistent with the present disclosure can be implemented as hardware orsoftware alone.

While the above examples describe providing alerts to user 120, it isunderstood that alert system 100 may also provide alerts to merchant140. For example, when user 120 swipes a bank card at a point of saleterminal at merchant 140, server 111 may analyze the historical fraud ordisputes data associated with user 120, and may determine that user 120has a low reputation score. Server 111 may provide a pre-purchase alertmessage to merchant 140 to notify merchant 140 that user 120 may have alow credit rating, a high risk for fraud, or a high likelihood to bringa dispute about the purchase in near future. Merchant 140 may takeappropriate measures (decline the purchase, require cash, etc.) toprevent potential loss based on information included in the pre-purchasealert message about user 120, or any additional information about user120 that server 111 may provide via options included in the pre-purchasealert message. For example, merchant 140 may be a car dealer, who maydecline to sell a car to user 120 after receiving a pre-purchase alertmessage from server 111 indicating that user 120 has a history ofbringing disputes or lawsuits against various car dealers. Pre-purchasealert messages may also include offers, promotions, discounts, orbenefits information that server 111 collects from various sources ofmerchant 140, such that merchant 140 may relay such information to user120 to promote sales, or such that merchant 140 may match a competitor'soffer in order to persuade user 120 to make the same purchase atmerchant 140 rather than at the competitor's store.

FIG. 12 is a flowchart showing an exemplary method 1200 for providing analert message to a user 120. In one example, method 1200 may be executedby server 111 to provide an alert message to the user 120 about atransaction. Server 111 may receive data relating to an activity, suchas, for example, a transaction of a user (step 1210). The data relatingto the activity (e.g., transaction) of the user 120 may include any datadiscussed above in connection with examples shown in other figures.Alternatively or additionally, the data relating to the activity of theuser may include additional data discussed below. It is understood thatany additional data discussed below may also be included in the datarelating to the activity of the user discussed above in other examples.

Server 111 may analyze the received data relating to the transaction(step 1220). Server 111 may determine, based on the analysis, whetherthe data relating to the transaction deviates from a set of dataassociated with the user 120 by more than a threshold value (step 1230).If server 111 determines that the data relating to the transactiondeviates from the set of data associated with the user 120 by more thanthe threshold value (Yes, step 1230), server 111 may send an alertmessage to a user device, 120A for example, associated with the user(step 1240). If server 111 determines that the data relating to thetransaction does not deviate from the set of data associated with theuser 120 by more than the threshold value (No, step 1230), server 111may terminate method 1200. It is understood that method 1200 may notinclude all of the steps shown in FIG. 12, and may include additionalsteps not shown in FIG. 12.

Examples that may trigger the sending of an alert message to the useraccording to method 1200 are discussed below. In one example, thereceived data relating to the transaction may include a posted (e.g.,settled) transaction amount charged by a merchant, such as a restaurant,a hotel, a car rental company, etc. When the merchant is a restaurant,the posted transaction amount may include a charge for food and agratuity, for example. When the merchant is a hotel, the postedtransaction amount may include a charge for a room, and a surcharge, forexample, for using long distance telephone services. When the merchantis a car rental company, the posted transaction amount may include arental fee for a car, and a fuel surcharge for filling the gas tank, forexample.

Referring to FIG. 12, a set of data associated with the user 120 mayinclude an authorized transaction amount authorized by the user for thetransaction, For example, the set of data associated with the user mayinclude an authorized food charge and gratuity for a meal provided by arestaurant, an authorized charge for a room and a surcharge for usinglong distance telephone services, or an authorized rental fee forrenting a car and a fuel surcharge for filling the gas tank. Theauthorized transaction amount may be included in a receipt the user 120receives from the merchant, for example.

As part of step 1220 or 1230, server 111 may compare the postedtransaction amount with the authorized transaction amount, and maydetermine, based on the comparison, whether the posted transactionamount deviates from the authorized transaction amount by more than athreshold value, The threshold value may be determined by server 111based on various factors, such as, for example, amounts charged bysimilar merchants for similar services or products provided to the user,or historical amounts spent by the user with the same merchant orsimilar merchants. For example, server 111 may compare the authorizedgratuity for a restaurant service (e.g., 15% of food charge) with theposted gratuity (e.g., 25% of the food charge). Server 111 may determinethat the posted gratuity deviates from the authorized gratuity by morethan the threshold value (e.g., $5), and may send an alert message tothe user 120.

In another example, a set of data associated with the user 120 mayinclude historical transaction data, such as a pattern of transactionsassociated with the user. Server 111 may compare the received datarelating to the transaction with the pattern of transactions associatedwith the user 120. The pattern of transactions may include a patternassociated with at least one of a volume of the transactions or anamount of the transactions. For example, the historical transaction datamay show that the user 120 has historically made five to ten purchasesper year with a merchant, such as, for example, an online contentprovider (e.g., an online music store or application store). In oneexample, server 111 may determine that five to ten purchases per year isan allowable range of transaction volume for this online contentprovider. Additionally or alternatively, the allowable range oftransaction volume may be defined by the user 120. The received datarelating to the transaction may include data indicating a recenttransaction volume between the user 120 and the online content providerin a recent time period (e.g., last month, last three months, etc.).Server 111 may determine whether the recent transaction volume fallswithin the allowable range of transaction volume associated with thisonline content provider. For example, if the recent transaction volumebetween the user and the online content provider is more than fifteenpurchases in the last month alone, server 111 may determine that therecent transaction volume does not fall within the allowable range oftransaction volume, and may send an alert message to the user 120regarding the last month's transactions.

As another example, the historical transaction data may show that theuser 120 has historically spent only $5 to $10 per year with the onlinecontent provider, for example. Server 111 may determine that $5 to $10per year is an allowable range of transaction amounts for this onlinecontent provider. Additionally or alternatively, the allowable range oftransaction amounts may be defined by the user 120. The received datarelating to the transaction may include data indicating a recenttransaction amount between the user 120 and the online content provider.Server 111 may determine whether the recent transaction amount fallswithin the allowable range of transaction amounts. For example, if therecent transaction amount between the user 120 and the online contentprovider is more than $20, server 111 may determine that the recenttransaction amount does not fall within the allowable range oftransaction amounts, and may send an alert message to the user regardingthe recent transaction.

In some examples, server 111 may categorize a plurality of users into aplurality of segments based on at least one of a demographic factor orone or more common characteristics reflected in transaction historiesassociated with the plurality of users. Users within a same segment mayshare similar demographic factors and/or similar characteristicsreflected in transaction histories. The demographic factor associatedwith a user may include at least one of age, sex, income, education,race, location, etc. For example, server 111 may categorize a firstgroup of users into a first segment based on the users' age (e.g., atleast 50 years old), the users' sex (e.g., male users only), the users'income (e.g., household income over $100,000 only), the users' education(e.g., users with college degrees only), the users' race (e.g., blackpeople only), or the users' locations (e.g., users located within 200miles of a particular zip code). Alternatively, server 111 maycategorize the first group of users into the first segment based on acombination of one or more of the demographic factors. When categorizingthe plurality of users into a first segment based on demographicfactors, server 111 may or may not consider the users' transactionhistories.

The transaction history of a user may include data showing certaintransactional characteristics, such as, for example, the transactionamounts (e.g., total spending in a certain period), the transactionvolumes (e.g., total number of purchases), the transaction types (e.g.,types of products or services purchased), dates and times oftransactions (including the frequency of transactions), and/or thelocations of the transactions (e.g., distance from the registered homeaddresses of the users). Server 111 may categorize the first group ofusers into the first segment based on one or more of the characteristicsreflected in the users' transaction histories. For example, server 111may categorize the first group of users into the first segment based onthe total spending of the users within a calendar year, the transactiontypes (e.g., electronics), the dates and times of transactions (e.g.,late night bar customers), the transaction volumes (e.g., nonsmokers whohave no transaction with a cigar store), and/or the locations of thetransactions (e.g., users who buy groceries from a grocery store locatedwithin ten miles from a home address, work address, etc.). In oneexample, the first segment may comprise users who spend below $10,000per year, or users who spend between $10,000 and $50,000 per year, orusers who spend above $50,000 per year, etc. In another example, thefirst segment may comprise users who go to the same or similar pharmacystore, or users who go to the same or similar grocery store, or userswho shop in the same or similar online stores. In another example, thefirst segment may comprise users who purchase the same brand ofcomputer, or users who use the same utility company, or users who usethe same hotel, airline, or rental car company, etc. In another example,the first segment may comprise users who shop on certain dates and/ortimes, such as Black Friday, within one week before Christmas, NewYear's Day, after midnight, during 9:00 p.m.-11:00 p.m., etc. In anotherexample, the first segment may comprise users who buy groceries from agrocery store located within ten miles from his/her work address, orusers who make purchases within a certain zone in a city, within fivemiles of a zip code, etc.

Other characteristics reflected in the transaction histories may also beused for categorizing users into segments. For example, users who havemore than ten disputes per year may be categorized into the samesegment. Users who often delay payments on credit card bills may becategorized into the same segment. Users who make more transactions thana certain transaction volume (e.g., five thousand transactions per year)using a particular bank card may be categorized into the same segment.Users who appear to own the same product (e.g., a vehicle from the samecar company, as may be reflected from a car loan or transactions made ata car dealer) may be categorized into the same segment.

Referring to FIG. 12, the set of data associated with the user 120 mayinclude information regarding at least one segment to which the userbelongs. Server 111 may compare the received data with the informationregarding the segment(s) to which the user 120 belongs. For example, thereceived data relating to a recent transaction made by the user 120 mayindicate a $100 purchase of cigars last month. The information regardingthe segment to which the user 120 belongs may indicate that the user 120belongs to a nonsmoker segment. Server 111 may compare the $100 purchaseof cigars with the information indicating that the user 120 belongs to anonsmoker segment, and may determine that the received data relating tothe recent transactions deviates from the information regarding thesegment to which the user belongs by a threshold value (e.g., $0 annualspending by users within the segment on cigars). Server 111 may send analert message to the user 120 about this transaction.

Computer programs based on the written description and methods of thisspecification are within the skill of a software developer. The variousprograms or program modules can be created using a variety ofprogramming techniques. For example, program sections or program modulescan be designed in or by means of Java, C, C++, HTML, assembly language,or any such programming languages. One or more of such software sectionsor modules can be integrated into a computer system, non-transitorycomputer-readable media, or existing communications software.

Moreover, while illustrative examples have been described herein, thescope includes any and all examples having equivalent elements,modifications, omissions, combinations (e.g., of aspects across variousexamples), adaptations or alterations based on the present disclosure.The elements in the claims are to be interpreted broadly based on thelanguage employed in the claims and not limited to examples described inthe present specification or during the prosecution of the application,which examples are to be construed as non-exclusive. Further, the stepsof the disclosed methods can be modified in any manner, including byreordering steps or inserting or deleting steps. It is intended,therefore, that the specification and examples be considered asexemplary only, with a true scope and spirit being indicated by thefollowing claims and their full scope of equivalents.

What is claimed is:
 1. A system for providing expedited disputeresolution, comprising: a memory device storing instructions; and atleast one processor configured to execute the instructions to performoperations comprising: receiving data relating to a transaction of auser with a merchant; comparing the data to an expected value associatedwith the user, the expected value being determined based on historicaltransaction data associated with the user; responsive to determining thedata deviates from the expected value by more than a threshold value,causing an alert message to be sent to a device of the user, the alertmessage causing a first graphical user interface to be displayed on thedevice of the user, wherein the first graphical user interface comprisesa first selectable option to receive information relating to themerchant; causing, in response to a selection of the first selectableoption, a second graphical user interface to be displayed on the deviceof the user, wherein the second graphical user interface comprisesdispute resolution information indicating an elevated rate of disputesfor the merchant and a second selectable option to dispute thetransaction; receiving, in response to the dispute resolutioninformation being displayed, a communication indicating that thetransaction is to be disputed; and initiating, based on a reputationscore of the merchant determined based on a history of disputedtransactions of the user, a dispute resolution process, wherein: if thereputation score is greater than a predetermined threshold score, thedispute resolution process comprises a standard dispute resolutionprocess, and if the reputation score is less than the predeterminedthreshold score, the dispute resolution process comprises an expediteddispute resolution process.
 2. The system of claim 1, wherein theexpedited dispute resolution process comprises: causing the transactionto be removed from an account of the user prior to the transaction beinginvestigated such that a financial server provider assumes a costassociated with the transaction if the transaction is resolved in favorof the merchant.
 3. The system of claim 1, wherein the history ofdisputed transactions of the user comprises (i) transactions where theuser initiated a dispute, and (ii) a resolution of each of thetransactions, wherein the reputation score of the user is determinedbased on the transactions and the resolution of each of thetransactions.
 4. The system of claim 1, wherein the historicaltransaction data indicates a detected pattern of transactions associatedwith the user.
 5. The system of claim 4, wherein comparing the data withthe expected value further comprises: comparing a transaction amountassociated with a merchant purchase with an allowable range oftransaction amounts associated with the user and based on the detectedpattern of transactions, wherein the operations further comprise:determining whether the transaction amount associated with the merchantis within the allowable range of transaction amounts associated with themerchant.
 6. The system of claim 5, wherein the operations furthercomprise: determining the allowable range of transaction amounts basedon the historical transaction data, the historical transaction datacomprising historical transaction amounts associated with the user. 7.The system of claim 4, wherein comparing the data with the expectedvalue comprises: comparing a transaction volume associated with themerchant with an allowable range of transaction volumes, the allowablerange of transaction volumes being associated with the merchant andbeing based on the detected pattern of transactions, wherein theoperations further comprise: determining whether the transaction volumeassociated with the merchant is within the allowable range oftransaction volumes associated with the merchant.
 8. The system of claim7, wherein the operations further comprise: determining the allowablerange of transaction volumes based on the historical transaction data,wherein the historical transaction data comprises historical transactionvolumes associated with the user.
 9. The system of claim 1, wherein theoperations further comprise: categorizing a group of users into asegment based on one or more similar transaction histories shared by thegroup of users, wherein the group of users includes the user, andwherein the expected value is further determined based on the user beinga member of the group of users.
 10. The system of claim 1, wherein thereputation score of the user is further determined based on a standingof the user with respect to a financial service provider, benefitsassociated with the user, or the standing of the user with respect tothe financial service provider and the benefits associated with theuser.
 11. Non-transitory computer-readable media storing computerprogram instructions that, when executed by one or more processors,effectuate operations comprising: receiving data relating to atransaction of a user with a merchant; comparing the data to an expectedvalue associated with the user, the expected value being determinedbased on historical transaction data associated with the user;responsive to determining the data deviates from the expected value bymore than a threshold value, causing an alert message to be sent to adevice of the user, the alert message causing a first graphical userinterface to be displayed on the device of the user, wherein the firstgraphical user interface comprises a first selectable option to receiveinformation relating to the merchant; causing, in response to aselection of the first selectable option, a second graphical userinterface to be displayed on the device of the user, wherein the secondgraphical user interface comprises dispute resolution informationindicating an elevated rate of disputes for the merchant and a secondselectable option to dispute the transaction; receiving, in response tothe dispute resolution information being displayed, a communicationindicating that the transaction is to be disputed; and initiating, basedon a reputation score of the merchant determined based on historicalfraud data associated with the merchant, a dispute resolution process,wherein: if the reputation score is greater than a predeterminedthreshold score, the dispute resolution process comprises a standarddispute resolution process, and if the reputation score is less than thepredetermined threshold score, the dispute resolution process comprisesan expedited dispute resolution process.
 12. The non-transitorycomputer-readable media of claim 11, wherein the expedited disputeresolution process comprises: causing the transaction to be removed froman account of the user prior to the transaction being investigated suchthat a financial server provider assumes a cost associated with thetransaction if the transaction is resolved in favor of the merchant. 13.The non-transitory computer-readable media of claim 11, wherein thehistorical fraud data comprises (i) transactions where the userinitiated a dispute, and (ii) a resolution of each of the transactions,wherein the reputation score of the user is determined based on thetransactions and the resolution of each of the transactions.
 14. Thenon-transitory computer-readable media of claim 11, wherein thehistorical transaction data indicates a detected pattern of transactionsassociated with the user.
 15. The non-transitory computer-readable mediaof claim 14, wherein comparing the data with the expected value furthercomprises: comparing a transaction amount associated with a merchantpurchase with an allowable range of transaction amounts associated withthe user and based on the detected pattern of transactions, wherein theoperations further comprise: determining whether the transaction amountassociated with the merchant is within the allowable range oftransaction amounts associated with the merchant.
 16. The non-transitorycomputer-readable media of claim 15, wherein the operations furthercomprise: determining the allowable range of transaction amounts basedon the historical transaction data, the historical transaction datacomprising historical transaction amounts associated with the user. 17.The non-transitory computer-readable media of claim 14, whereincomparing the data with the expected value comprises: comparing atransaction volume associated with the merchant with an allowable rangeof transaction volumes, the allowable range of transaction volumes beingassociated with the merchant and being based on the detected pattern oftransactions, wherein the operations further comprise: determiningwhether the transaction volume associated with the merchant is withinthe allowable range of transaction volumes associated with the merchant.18. The non-transitory computer-readable media of claim 17, wherein theoperations further comprise: determining the allowable range oftransaction volumes based on the historical transaction data, whereinthe historical transaction data comprises historical transaction volumesassociated with the user.
 19. The non-transitory computer-readable mediaof claim 11, wherein the operations further comprise: categorizing agroup of users into a segment based on one or more similar transactionhistories shared by the group of users, wherein the group of usersincludes the user, and wherein the expected value is further determinedbased on the user being a member of the group of users.
 20. A methodimplemented by one or more processors executing one or more computerprogram instructions that, when executed, perform the method, the methodcomprising: receiving data relating to a transaction of a user with amerchant; comparing the data to an expected value associated with theuser, the expected value being determined based on historicaltransaction data associated with the user; responsive to determining thedata deviates from the expected value by more than a threshold value,causing an alert message to be sent to a device of the user, the alertmessage causing a first graphical user interface to be displayed on thedevice of the user, wherein the first graphical user interface comprisesa first selectable option to receive information relating to themerchant; causing, in response to a selection of the first selectableoption, a second graphical user interface to be displayed on the deviceof the user, wherein the second graphical user interface comprisesdispute resolution information indicating an elevated rate of disputesfor the merchant and a second selectable option to dispute thetransaction; receiving, in response to the dispute resolutioninformation being displayed, a communication indicating that thetransaction is to be disputed; and initiating, based on a reputationscore of the merchant determined based on a history of disputedtransactions of the user, a dispute resolution process, wherein: if thereputation score is greater than a predetermined threshold score, thedispute resolution process comprises a standard dispute resolutionprocess, and if the reputation score is less than the predeterminedthreshold score, the dispute resolution process comprises an expediteddispute resolution process.